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Abstract 


This paper presents a new static type system for multi- 
threaded programs; well-typed programs in our system are 
guaranteed to be free of data races and deadlocks. Our type 
system allows programmers to partition the locks into a fixed 
number of equivalence classes and specify a partial order 
among the equivalence classes. The type checker then stat- 
ically verifies that whenever a thread holds more than one 
lock, the thread acquires the locks in the descending order. 


Our system also allows programmers to use recursive tree- 
based data structures to describe the partial order. For ex- 
ample, programmers can specify that nodes in a tree must 
be locked in the tree-order. Our system allows mutations to 
the data structure that change the partial order at runtime. 
The type checker statically verifies that the mutations do not 
introduce cycles in the partial order, and that the changing 
of the partial order does not lead to deadlocks. We do not 
know of any other sound static system for preventing dead- 
locks that allows changes to the partial order at runtime. 


1 Introduction 


The use of multiple threads of control is quickly becoming 
a mainstream programming practice. But interactions be- 
tween threads can significantly complicate the software de- 
velopment process. Multithreaded programs typically syn- 
chronize operations on shared mutable data to ensure that 
the operations execute atomically. Failure to correctly syn- 
chronize such operations can lead to data races or deadlocks. 
A data race occurs when two threads concurrently access 
the same data without synchronization, and at least one of 
the accesses is a write. A deadlock occurs when there is a 
cycle of the form: Vi € {0... — 1}, Thread; holds Lock; and 
Thread; is waiting for Lock(+1) moa n» Synchronization er- 
rors in multithreaded programs are among the most difficult 
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programming errors to detect, reproduce, and eliminate. 


This paper presents a new static type system for multi- 
threaded programs; well-typed programs in our system are 
guaranteed to be free of data races and deadlocks. In recent 
previous work, we presented a static type system to prevent 
data races [3]. In this paper, we extend the race-free type 
system to prevent both data races and deadlocks. The basic 
idea behind our system is as follows. When programmers 
write multithreaded programs, they already have a locking 
discipline in mind. Our system allows programmers to spec- 
ify this locking discipline in their programs. The resulting 
specifications take the form of type declarations. 


1.1 Deadlock Freedom 


To prevent deadlocks, programmers partition all the locks 
into a fixed number of lock levels and specify a partial order 
among the lock levels. The type checker statically verifies 
that whenever a thread holds more than one lock, the thread 
acquires the locks in the descending order. Our type system 
allows programmers to write code that is polymorphic in 
lock levels. Programmers can specify a partial order among 
formal lock level parameters using where clauses. This is 
somewhat similar to the use of where clauses in [11, 24]. 


Our system also allows programmers to use recursive tree- 
based data structures to further order the locks that belong 
to the same lock level. For example, programmers can spec- 
ify that nodes in a tree must be locked in the tree-order. Our 
system allows mutations to the data structure that change 
the partial order at runtime. The type checker uses an intra- 
procedural intra-loop flow-sensitive analysis to statically ver- 
ify that the mutations do not introduce cycles in the partial 
order, and that the changing of the partial order does not 
lead to deadlocks. We do not know of any other sound static 
system for preventing deadlocks that allows changes to the 
partial order at runtime. 


1.2 Data Race Freedom 


To prevent data races, programmers associate every object 
with a protection mechanism that ensures that accesses to 
the object never create data races. The protection mech- 
anism of an object can specify either the mutual exclusion 
lock that protects the object from unsynchronized concur- 
rent accesses, or that threads can safely access the object 
without synchronization because either 1) the object is im- 
mutable, 2) the object is accessible to a single thread, or 
3) the variable contains the unique pointer to the object. 
Unique pointers are useful to support object migration be- 


tween threads. The type checker statically verifies that a 
program uses objects only in accordance with their declared 
protection mechanisms. 


Our type system is significantly more expressive than previ- 
ously proposed type systems for preventing data races [15, 
2]. In particular, our type system lets programmers write 
generic code to implement a class, then create different ob- 
jects of the class that have different protection mechanisms. 
We do this by introducing a way of parameterizing classes 
that lets programmers defer the protection mechanism deci- 
sion from the time when a class is defined to the times when 
objects of that class are created. 


1.3 Contributions 


This paper makes the following contributions: 


e Static Type System to Prevent Deadlocks: This 
paper presents a new static type system to prevent 
deadlocks in Java programs. Our system allows pro- 
grammers to partition all the locks into a fixed number 
of lock levels and specify a partial order among the 
lock levels. The type checker then statically verifies 
that whenever a thread holds more than one lock, the 
thread acquires the locks in the descending order. 


e Formal Rules for Type Checking: To simplify the 
presentation of key ideas behind our approach, this 
paper formally presents our type system in the context 
of a core subset of Java called Concurrent Java[3, 15, 
16]. Our implementation, however, works for the whole 
of the Java language. 


e Type Inference Algorithm: Although our type sys- 
tem is explicitly typed in principle, it would be onerous 
to fully annotate every method with the extra type in- 
formation that our system requires. Instead, we use 
a combination of intra-procedural type inference and 
well-chosen defaults to significantly reduce the num- 
ber of annotations needed in practice. Our approach 
permits separate compilation. 


e Lock Level Polymorphism: Our type system al- 
lows programmers to write code where the exact levels 
of some locks are not known statically—only some or- 
dering constraints among the unknown lock levels are 
known statically. Our system uses lock level polymor- 
phism to support this kind of programming. Program- 
mers can specify a partial order among formal lock level 
parameters using where clauses. This is somewhat sim- 
ilar to the use of where clauses in [11, 24]. 


e Support for Condition Variables: In addition to 
mutual exclusion locks, our type system prevents dead- 
locks in the presence of condition variables. Our sys- 
tem statically enforces the constraint that a thread can 
invoke e.wait only if the thread holds no locks other 
than the lock on e. Since a thread releases the lock 
on e€ on executing e.wait, the above constraint implies 
that any thread that is waiting on a condition variable 
holds no locks. This in turn implies that there cannot 
be a deadlock that involves a condition variable. Our 
system thus prevents the nested monitor problem [22]. 


e Partial-Orders Based on Mutable Trees: Our 
system also allows programmers to use recursive tree- 
based data structures to further order the locks that 
belong to the same lock level. Our system allows muta- 
tions to the trees that change the partial order at run- 
time. The type checker uses an intra-procedural intra- 
loop flow-sensitive analysis to statically verify that the 
mutations do not introduce cycles in the partial order, 
and that the changing of the partial order does not 
lead to deadlocks. 


e Partial-Orders Based on Monotonic DAGs: Our 
system also allows programmers to use recursive DAG- 
based data structures to order the locks that belong to 
the same lock level. DAG edges cannot be modified 
once initialized. Only newly created nodes may be 
added to a DAG by initializing the newly created nodes 
to contain DAG edges to existing DAG nodes. 


e Implementation: We have a prototype implementa- 
tion of our type system. Our implementation handles 
all the features of the Java language including threads, 
constructors, arrays, exceptions, static fields, and run- 
time downcasts. We also modified some Java server 
programs and implemented them in our system. These 
programs exhibit a variety of sharing patterns. Our 
experience indicates that our system is sufficiently ex- 
pressive and requires little programming overhead. 


1.4 Outline 


The rest of this paper is organized as follows. Section 2 in- 
troduces our type system using two examples. Section 3 de- 
scribes a core subset of Java that we use to formally describe 
our type system. Our implementation, however, works for 
the whole of the Java language. Sections 4 and 5 present 
our basic type system that prevents both data races and 
deadlocks. Section 6 describes some important rules for 
type checking. The full set of typing rules are presented 
in the appendix. Section 7 contains our type inference algo- 
rithm that significantly reduces the programming overhead. 
Section 8 shows how our type system supports lock level 
polymorphism, while Section 9 shows how our type system 
prevents deadlocks in the presence of condition variables. 
Section 10 presents tree-based partial orders and Section 11 
presents DAG-based partial orders. Section 12 describes our 
implementation. Section 13 presents related work and Sec- 
tion 14 concludes. 


2 Examples 


This section introduces our type system with two examples. 
The later sections explain our type system in greater detail. 


2.1 Combined Account Example 


Figure 1 presents an example program implemented in our 
type system. The program has an Account class and a Com- 
binedAccount class. To prevent data races, programmers as- 
sociate every object in our system with a protection mecha- 
nism. In the example, the CombinedAccount class is declared 
to be immutable. A CombinedAccount may not be modified 
after initialization. The Account class is generic—different 
Account objects may have different protection mechanisms. 


1 class Account { 
2 int balance = 0; 
3 
4 int balance() accesses (this) { return balance; } 
5 void deposit(int x) accesses (this) { balance += x; } 
6 void withdraw(int x) accesses (this) { balance -= x; } 
i 
8 
9 class CombinedAccount<readonly> { 
10 LockLevel savingsLevel = new; 
11 LockLevel checkingLevel < savingsLevel; 
12 final Account<self:savingsLevel> savingsAccount 
13 = new Account; 
14 final Account<self:checkingLevel> checkingAccount 
15 = new Account; 
16 
Ng void transfer(int x) locks(savingsLevel) { 
18 synchronized (savingsAccount) { 
19 synchronized (checkingAccount) { 
20 savingsAccount .withdraw(x) ; 
21 checkingAccount .deposit (x) ; 
22 33} 
23 int creditCheck() locks(savingsLevel) { 
24 synchronized (savingsAccount) { 
25 synchronized (checkingAccount) { 
26 return savingsAccount.balance() + 
27 checkingAccount .balance() ; 
28 33} 
29 ara 
30 } 


Figure 1: Combined Account Example 


The CombinedAccount class contains two Account fields— 
savingsAccount and checkingAccount. The key word self in- 
dicates that these two Account objects are protected by their 
own locks. The type checker statically ensures that a thread 
holds the locks on these Account objects before accessing the 
Account objects. 


To prevent deadlocks, programmers associate every lock in 
our system with a lock level. In the example, the Com- 
binedAccount class declares two lock levels—savingsLevel and 
checkingLevel. Lock levels are purely compile-time entities— 
they are not preserved at runtime. In the example, check- 
ingLevel is declared to rank lower than savingsLevel in the 
partial order of lock levels. The checkingAccount belongs 
to checkingLevel, while the savingsAccount belongs to sav- 
ingsLevel. The type checker statically ensures that threads 
acquire these locks in the descending order of lock levels. 


Methods in our system may contain accesses clauses to spec- 
ify assumptions that hold at method boundaries. The meth- 
ods of the Account class each have an accesses clause that 
specifies that the methods access the this Account object 
without synchronization. To prevent data races, our type 
checker requires that the callers of Account methods must 
hold the locks that protect the corresponding Account object 
before the callers can invoke any of the Account methods. 
Without the accesses clauses, the Account methods would 
not have been well-typed. 


Methods in our system may also contain locks clauses. The 
methods of the CombinedAccount class contain a locks clause 
to indicate to callers that they may acquire locks that belong 
to lock levels savingsLevel or lower. To prevent deadlocks, the 
type checker statically ensures that callers of CombinedAc- 


1 class BalancedTree { 

2 LockLevel 1 = new; 

3 Node<self:1> root = new Node; 

4 } 

5 

6 class Node<self:v> { 

7 tree Node<self:v> left; 

8 tree Node<self:v> right; 

9 

10 // this this 

11 : ar oe’ / \ 

12 ioe tgs 8 

13 // 7X mica /\ 

14 // vey u x 

15 // /\ /\ 

16 // uw wey 

17 

18 synchronized void rotateRight() locks(this) { 
19 final Node x = this.right; if (x == null) return; 
20 synchronized (x) { 
21 final Node v = x.left; if (v == null) return; 
22 synchronized (v) { 
23 final Node w = v.right; 
24 v.right = null; 
25 x.left = w; 
26 this.right = v; 
27 v.right = x; 
28 haga 
29 soit 
30 } 


Figure 2: Tree Example 


count methods only hold locks that are of greater lock levels 
than savingsLevel. Like the accesses clauses, the locks clauses 
are useful to enable separate compilation. 


2.2 Tree Example 


Figure 2 presents part of a BalancedTree implemented in our 
type system. A BalancedTree is a tree of Nodes. Every Node 
object is declared to be protected by its own lock. To prevent 
data races, the type checker statically ensures that a thread 
holds the lock on a Node object before accessing the Node 
object. 


The Node class is parameterized by the formal lock level v. 
The Node class has two Node fields—left and a right. The 
Nodes left and right also belong to the same lock level v. 


Our system also allows programmers to use recursive tree- 
based data structures to further order the locks that belong 
to the same lock level. In the example, the key word tree 
indicates that the Nodes left and right are ordered less than 
the this Node object in the partial order. To prevent dead- 
locks, the type checker statically verifies that the rotateRight 
method acquires the locks on Nodes this, x and v in the tree- 
order. 


The rotateRight method in the example performs a standard 
rotation operation on the tree to restore the tree balance. 
The type checker uses an intra-procedural intra-loop flow- 
sensitive analysis to statically verify that the mutations do 
not introduce cycles in the partial order, and that the chang- 
ing of the partial order does not lead to deadlocks. 


Our type system thus statically verifies the absence of both 
data races and deadlocks in the above examples. 


Pes defn? é 
defn ::= class cn extends c body 
ce := cn | Object 
body ::=  {field* meth*} 
meth i= t mn(arg*) {e} 
field ::=  [finallopt t fd = e 
arg := [finallope t « 
t ::=  c | int | boolean 
e n= newc|z|x2=e|e.fd|e.fd = e|e.mn(e*) | 
e;e | let (arg = e) in {e} | if (e) then {e} | 
synchronized (e) in {e} | fork (~*) {e} 
cn € class names 
fda € field names 
mn € method names 
AA € variable names 


Figure 3: Grammar for Concurrent Java 


3 Core Subset of Java 


This section presents Concurrent Java [3, 15], a core subset 
of Java [17] with formal semantics. To simplify the presenta- 
tion of key ideas behind our approach, we describe our type 
system formally in the context of Concurrent Java. Our 
implementation, however, works for the whole of the Java 
language. Concurrent Java is an extension to a sequential 
subset of Java known as Classic Java [16], and has much 
of the same type structure and semantics as Classic Java. 
Figure 3 shows the grammar for Concurrent Java. 


Each object in Concurrent Java has an associated lock that 
has two states—locked and unlocked—and is initially un- 
locked. The expression fork(z*) {e} spawns a new thread 
with arguments (z*) to evaluate e. The evaluation is per- 
formed only for its effect; the result of e is never used. Note 
that the Java mechanism of staring threads using code of the 
form {Thread t=...; t.start();} can be expressed equivalently 
in Concurrent Java as {fork(t) {¢.start();}}. The expression 
synchronized (e1) in {e2} works as in Java. e; should eval- 
uate to an object. The evaluating thread holds the lock on 
object e1 while evaluating e2. The value of the synchronized 
expression is the result of ez. While one thread holds a lock, 
any other thread that attempts to acquire the same lock 
blocks until the lock is released. A newly forked thread does 
not inherit locks held by its parent thread. 


A Concurrent Java program is a sequence of class definitions 
followed by an initial expression. A predefined class Object 
is the root of the class hierarchy. Each variable and field 
declaration in Concurrent Java includes an initialization ex- 
pression and an optional final modifier. If the modifier is 
present, then the variable or field cannot be updated after 
initialization. Other Concurrent Java constructs are similar 
to the corresponding constructs in Java. 


4 Type System to Prevent Data Races 


This section presents our type system for preventing data 
races in the context of Concurrent Java. Programmers asso- 
ciate every object with a protection mechanism that ensures 
that accesses to the object never create data races. Pro- 
grammers specify the protection mechanism for each object 
as part of the type of the variables that refer to that ob- 
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Thread1 Objects Thread2 Objects Potentially Shared Objects 


Figure 4: An Ownership Relation 


1. The owner of an object does not change over time. 


2. The ownership relation forms a forest of rooted trees, 
where the roots can have self loops. 


3. The necessary and sufficient condition for a thread to 
access to an object is that the thread must hold the 
lock on the root of the ownership tree that the object 
belongs to. 


4. Every thread implicitly holds the lock on the corre- 
sponding thisThread owner. A thread can therefore ac- 
cess any object owned by its corresponding this Thread 
owner without any synchronization. 


Figure 5: Ownership Properties 


ject. The type can specify either the mutual exclusion lock 
that protects the object from unsynchronized concurrent ac- 
cesses, or that threads can safely access the object without 
synchronization because either 1) the object is immutable, 
2) the object is accessible to a single thread, or 3) the vari- 
able contains the unique pointer to the object. Unique point- 
ers are useful to support object migration between threads. 
The type checker then uses these type specifications to stat- 
ically verify that a program uses objects only in accordance 
with their declared protection mechanisms. 


This section only describes our basic type system that han- 
dles objects protected by mutual exclusion locks and thread- 
local objects that can be accessed without synchronization. 
Our race-free type system also supports unsynchronized ac- 
cesses to immutable objects and objects with unique pointers 
that can migrate between threads. Our race-free type sys- 
tem is described in greater detail in [3]. The key to our basic 
race-free type system is the concept of object ownership. Ev- 
ery object in our system has an owner. An object can be 
owned by another object, by itself, or by a special per-thread 
owner called thisThread. Objects owned by thisThread, ei- 
ther directly or transitively, are local to the corresponding 
thread and cannot be accessed by any other thread. Fig- 
ure 4 presents an example ownership relation. We draw an 
arrow from object x to object y in the figure if object x owns 
object y. Our type system statically verifies that a program 
respects the ownership properties shown in Figure 5. 


Figure 6 shows how to obtain the grammar for Race-Free 
Java by extending the grammar for Concurrent Java. Fig- 
ure 7 shows a TStack program in Race-Free Java. For sim- 
plicity, all the examples in this paper use an extended lan- 
guage that is syntactically closer to Java. A TStack is a stack 


defn ::= class cn(owner formal*) extends c body 
c n= cn(owner+) | Object(owner+) 
owner ::= formal | self | thisThread | efinai 
meth = t mn(arg*) accesses (efina*) {e} 
€final = e 
formal := f 
f € owner names 


Figure 6: Grammar Extensions for Race-Free Java 


of T objects. A TStack is implemented using a linked list. A 
class definition in Race-Free Java is parameterized by a list 
of owners. This parameterization helps programmers write 
generic code to implement a class, then create different ob- 
jects of the class that have different protection mechanisms. 
In Figure 7, the TStack class is parameterized by thisOwner 
and TOwner. thisOwner owns the this TStack object and 
TOwner owns the T objects contained in the TStack. In gen- 
eral, the first formal parameter of a class always owns the this 
object. In case of sl, the owner thisThread is used for both 
the parameters to instantiate the TStack class. This means 
that the main thread owns TStack s1 as well as all the T ob- 
jects contained in the TStack. In case of s2, the main thread 
owns the TStack but the T objects contained in the TStack 
own themselves. The ownership relation for the TStack ob- 
jects sl and s2 is depicted in Figure 8 (assuming the stacks 
contains three elements each). This example illustrates how 
different TStacks with different protection mechanisms can 
be created from the same TStack implementation. 


In Race-Free Java, methods can contain accesses clauses to 
specify the assumptions that hold at method boundaries. 
Methods specify the objects they access that they assume are 
protected by externally acquired locks. Callers are required 
to hold the locks on the root owners of the objects specified 
in the accesses clause before they invoke a method. In the 
example, the value and next methods in the TNode class 
assume that the callers hold the lock on the root owner of 
the this TNode object. Without the accesses clause, the value 
and next methods would not have been well-typed. 


5 Type System to Prevent Deadlocks 


This section presents our type system for preventing both 
data races and deadlocks in the context of Concurrent Java. 
To prevent deadlocks, programmers specify a partial order 
among all the locks. The type checker statically verifies that 
whenever a thread holds more than one lock, the thread 
acquires the locks in the descending order. This section only 
describes our basic type system that allows programmers 
to partition the locks into a fixed number of equivalence 
classes and specify a partial order among the equivalence 
classes. Our system also allows programmers to use recursive 
tree-based data structures to describe the partial order— 
we describe how our type system handles tree-based partial 
orders in Section 10. 


Figure 9 describes how to obtain the grammar for Deadlock- 
Free Java by extending the grammar for Race-Free Java. 
We call the resulting language Safe Concurrent Java. Safe 
Concurrent Java allows programmers to define lock levels in 
class definitions. A lock level is like a static field in Java— 


// thisOwner owns the TStack object 
// TOwner owns the T objects in the stack. 


1 
2 
3 
4 class TStack<thisOwner, TOwner> { 
6 TNode<this, TOwner> head = null; 
7 
8 


T<TOwner> pop() accesses (this) { 


9 if (head == null) return null; 
10 T<TOwner> value = head.value(); 
11 head = head.next(); 
12 return value; 
13 } 
14 sole 
15 r 
16 class TNode<thisOwner, TOwner> { 
17 T<TOwner> value; 
18 TNode<thisOwner, TOwner> next; 
19 
20 T<TOwner> value() accesses (this) { 
21 return value; 
22 i. 
23 TNode<thisOwner, TOwner> next() accesses (this) { 
24 return next; 
25 F 
26 on 
27 } 
28 class T<thisOwner> { int x=0; } 
29 
30 TStack<thisThread, thisThread> si = 
31 new TStack<thisThread, thisThread>; 
32 TStack<thisThread, self> s2 = 
33 new TStack<thisThread, self>; 


Figure 7: Stack of T Objects in Race-Free Java 
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Ee ae 


slheadfext.next s2.head s2.head.next _s2.head.next.next 
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sl (TStack) 


sl.head 
(TNode) 


s1head.value O 
(1) s1.head.next.value (t) 


s|.head.next.next.value Q 
s2.head.value s2.head.next.next.value 
(T)  s2.head.next.value 


Figure 8: Ownership Relation for TStacks sl and s2 


a lock level is a per-class entity rather than a per-object 
entity. But unlike static fields in Java, lock levels are used 
only for compile-time type checking and are not preserved 
at runtime. Programmers can specify a partial order among 
the lock levels using the < and > syntax in the lock level 
declarations. Since a program has a fixed number of lock 
levels, our type checker can statically verify that the lock 
levels do indeed form a partial order. Every lock in Safe 
Concurrent Java belongs to some lock level. Note that the 
set of locks in Race-Free Java is exactly the set of objects 
that are the roots of ownership trees. A lock is, therefore, 
an object that has self as its first owner. In Safe Concurrent 
Java, every self owner is augmented with the lock level that 
the corresponding lock belongs to. The properties of our 
lock levels are summarized in Figure 10. 


In the example shown in Figure 1, the CombinedAccount 
class defines two lock levels—savingsLevel and checkingLevel. 
checkingLevel is declared to be less than savingsLevel. A Com- 
binedAccount contains a savingsAccount and a checkingAc- 
count. These objects have self as their first owners—these 
objects are therefore locks. The savingsAccount is declared to 


body ::=  {level* field* meth*} 
level ::= LockLevel 1 = new | LockLevel | < cn.I* > cn.l* 
owner ::= formal | self:cn.l | thisThread | e¢inai 
meth i= t mn(arg*) accesses (final *) locksclause {e} 
locksclause ::= locks (cn.l* lock*) 
lock ‘= final 


I lock level names 


MM 


Figure 9: Grammar Extensions for Deadlock-Free Java 


1. The lock levels form a partial order. 


2. Objects that own themselves are locks. Every lock 
belongs to some lock level. The lock level of a lock 
does not change over time. 


3. The necessary and sufficient condition for a thread to 
acquire a new lock I is that the levels of all the locks 
that the thread currently holds are greater than the 
level of J. 


4. A thread may also acquire a lock that it already holds. 
The lock acquire operation is redundant in that case. 


Figure 10: Lock Level Properties 


belong to savingsLevel while the checkingAccount is declared 
to belong to checkingLevel. In the example, both the meth- 
ods of CombinedAccount acquire the lock on savingsAccount 
before they acquire the lock on checkingAccount to satisfy 
the condition that locks must be acquired in the descending 
order. 


Methods in Safe Concurrent Java can have locks clauses 
in addition to accesses clauses to specify assumptions at 
method boundaries. A locks clause can contain a set of lock 
levels. These lock levels are the levels of locks that the cor- 
responding method may acquire. To ensure that a program 
is free of deadlocks, a thread that calls the method can only 
hold locks that are of a higher level than the levels specified 
in the locks clause. In the example in Figure 1, both the 
methods of CombinedAccount contain a locks(savingsLevel) 
clause. A thread that invokes either of these methods can 
only hold locks whose level is greater than savingsLevel. 


A locks clause can also contain locks in addition to lock lev- 
els. If a locks clause contains an object J, then a thread 
that invokes the corresponding method must either hold the 
lock on object | (in which case re-acquiring the lock within 
the method is redundant), or the thread can only hold locks 
whose level is greater than the level of /. This is useful to 
support the case where a synchronized method of a class 
calls another synchronized method of the same class. Fig- 
ure 11 shows part of a self-synchronized Vector implemented 
in Safe Concurrent Java.! A self-synchronized class is a class 
that has self as its first owner instead of a formal owner pa- 
rameter. Methods of a self-synchronized class can assume 
that the this object owns itself—the methods can therefore 
synchronize on this and access the this object without requir- 
ing external locks using the accesses clause. In the example, 


TAs we mentioned before, all the examples in this paper use 
an extended language that is syntactically closer to Java. 


1 class Vector<self:Vector.1, elementOwner> { 
2 LockLevel 1 = new; 

3 

4 int elementCount = 0; 

5 ee 

6 int size() locks (this) { 

t synchronized (this) { 

8 return elementCount; 

9 3} 

10 

11 boolean isEmpty() locks (this) { 
12 synchronized (this) { 

13 return (size() == 0); 

14 ams 

15 } 


Figure 11: Self-Synchronized Vector 


the isEmpty method acquires the lock on this and invokes 
the size method which also acquires the lock on this. This 
does not violate our condition that locks must be acquired 
in the descending order because the second lock acquire is 
redundant. 


6 Type Checking 


The previous sections presented the grammar for Safe Con- 
current Java in Figures 3, 6, and 9. This section describes 
some of the important rules for type checking. The full set 
of rules and the complete grammar can be found in the ap- 
pendix. 


6.1 Rules for Type Checking 

The core of our type system is a set of rules for reasoning 
about the typing judgment: P; E; Is; lmin F e: t. P, the 
program being checked, is included here to provide informa- 
tion about class definitions. E’ is an environment providing 
types for the free variables of e. ls describes the set of locks 
held when e is evaluated. [min is the minimum level among 
the levels of all the locks held when e is evaluated. t¢ is the 
type of e. 


The judgment P; E' | e: t states that e is of type t, while 
the judgment P; E; Is; lmin F e: t states that e is of type 
t provided ls contains the necessary locks to safely evaluate 
e and Imin is greater that the levels of all the locks that are 
newly acquired when evaluating e. 


A typing environment E is defined as follows, where f is a 
formal owner parameter of a class. 


E:=0 | E, ffinallopt ¢ x | E, owner f 


A lock set ls is defined as follows, where RO(z) is the root 
owner of x. 


ls ::= thisThread | ls, lock | ls, RO(egnai) 


A minimum lock level Imin is defined as follows, where 
LUB(eni.lh ... cnkle) > enili Vie1..r. Note that LUB(...) 
is not computed—it is just an expression used as such for 
type checking. The lock level co denotes that no locks are 
currently held. 


lmin = 00 | en.l | LUB(eny.l1 ... eng-lp) 


The rule for fork e checks the expression e using a lock set 
that contains thisThread and is otherwise empty. Since a 
new thread does not inherit locks held by its parent, Imin for 
the child is set to oo. The environment E might have some 
types that contain thisThread. But the owner thisThread in 
the parent thread is not the same as the owner thisThread 
in the child thread. So, all the thisThread owners in the 
environment must be changed to something else; we use the 
special owner otherThread for that. 


[EXP FORK] 


P; FE; ls; lmin b ap: ti 
gi = final t;[otherThread/thisThread] 2; 
P; gi..n; thisThread; co Fe: t 
P; E3; 1s; lmin & fork (a1..n) fe} : int 


The rule for acquiring a new lock using synchronized e; in e2 
checks that e; is a lock of some level cn.l. The rule checks 
that cn.l is less than Imin. The rule then type checks e2 in 
an extended lock set that includes e; and with Imin set to 
cn.l. A lock is a final expression that owns itself. A final 
expression is either a final variable, or a field access e.fd 
where e is a final expression and fd is a final field. 


[EXP SYNC] 
P; EF gnai e1 : cn'(self:cn.l ...) 


Ptrenl < lmin 
P; E; ls, e1; en.LbF eg: to 
P; E; ls; lmin / synchronized e1 in eg : te 


Before we proceed further with the rules, we give a formal 
definition for RootOwner(e). The root owner of an expres- 
sion e that refers to an object is the root of the ownership 
tree to which the object belongs. It could be thisThread, or 
an object that owns itself. 


[ROOTOWNER THISTHREAD] 


P; Et e: en(thisThread ox) 
P; E+ RootOwner(e) = thisThread 


[ROOTOWNER SELF] 


P; Et e: cn(self:cn’.l’ ox) 
P; E + RootOwner(e) = e 


[ROOTOWNER FINAL TRANSITIVE] 


P; Ete: en(o1,.n) 
P; EF gna 01: ¢c1 P; E+ RootOwner(o1) =r 
P; E+} RootOwner(e) = r 


If the owner of an expression is a formal owner parameter, 
then we cannot determine the root owner of the expression 
from within the static scope of the enclosing class. In that 
case, we define the root owner of e to be RO(e). 


[ROOTOWNER FORMAL] 


P; Ete: cn(01..n) 
E = Ej, owner 01, E2 
P; E+ RootOwner(e) = RO(e) 


The rule for accessing field e.fd checks that e is a well-typed 
expression of some class type cn(01..n), where 01,.n are actual 
owner parameters. It verifies that the class cn with formal 
parameters fi... declares or inherits a field fd of type t and 
that the thread holds the lock on the root owner of e. Since 
t is declared inside the class, it might contain occurrences of 
this and the formal class parameters. When t is used outside 
the class, we rename this with the expression e, and the for- 
mal parameters with their corresponding actual parameters. 
The rule for assigning to a field is similar. 


[EXP REF] 
P; E; 1s; lnin F e : cn(o1..n) 
PF ([finallope ¢ fd) € en(fi..n) 
P; E+ RootOwner(e) =r réls 
P; E; ls; lnin | e.fd: tle/this][o1/f1]..[on/fn] 


[EXP ASSIGN] 
P; E; ls; lmin F e : en(o1..n) 
Pt (t fd) € en(fi..n) 
P; E+ RootOwner(e) =r réls 
P; E; 1s; lnin & e’ : tle/this][o1/fi]..[on/fn] 
P; E; 1s; lnin F e.fd = e’ : t[e/this][o1/fi]..[on/fn] 


The rule for invoking a method checks that the arguments 
are of the right type and that the thread holds the locks on 
the root owners of all final expressions in the accesses clause 
of the method. The rule ensures that lmin is greater than all 
the levels specified in the locks clause of the method. The 
rule also ensures that for all the locks specified in the locks 
clause, either the lock is in the lock set (in which case acquir- 
ing that lock within the method is redundant), or the level 
of that lock is less than [min. The expressions and types used 
inside the method are renamed appropriately when used out- 
side their class. 


[EXP INVOKE] 
P; E; 1s; lnin & € : cn(01..n) 
PF (t mn(t; yj 7€1-*) accesses(e’«) 
locks(en.l* locke) ...) € en(fi.n) 
P; Ej Is; lmin F e3 + ty[e/this][o1/fi]..[on/fn] 
P; E+} RootOwner(e}[e/this][o1/f1]..[on/fn]) = rj 


, rl els 


Pil cngl ee date: 
(P; Ef level(lock;) < lmin) or (lock; € Is) 


P; E; 1s; lnin & e.mn(ey..~) : tle/this][o1/f1]..[on/ fn] 


The rule for type checking a method assumes that the locks 
on the root owners of all the final expressions specified in 
the accesses clause are held. The rules also assumes that the 


levels of all the locks held by the thread are greater than the 
levels specified in the locks clause and the levels of the locks 
specified in the locks clause. The rule then type checks the 
method body under these assumptions. 


[METHOD] 
P; E, argi.in tinal ei: ti 


P; E, argi.n - RootOwner(e;) = ri 
ls = thisThread, ri. 


P; E, argi.m + level(lock;) = ent, I. 
lmin = LUB(cnj.; 964° oni. 9€1-1) 


P; Ey, argi..n;3 ls; lmin Fe: t 


P; Et t mn(argi..n) accesses(e1,.,) 
locks(cnj.lj 7€1* locky..1) {e} 


Our type checker also statically verifies that the lock levels 
declared in the program do indeed form a partial order. Our 
type checker ensure that there is no cycle of the following 
form. 


[PARTIAL ORDER] 


englgn etn nile such that 
Vizo..n-1 PF enj.ly < cnj.lj, where j = (i +1) mod n 
P+ 7 LockLevelsOK(P) 


6.2. Soundness of the Type System 


Our type checking rules ensure that for a program to be 
well-typed, the program respects the properties described 
in Figures 5 and 10. In particular, our type checking rules 
ensure that a thread can read or write an object only if the 
thread holds the lock on the root owner of that object, and 
that whenever a thread holds more than one lock, the thread 
acquires the locks in the descending order. The properties 
in Figure 5 imply that program is free of data races, while 
the properties in Figure 10 imply that a program is free of 
deadlocks. Well-typed programs in our system are therefore 
guaranteed to be free of both data races and deadlocks. 


A complete syntactic proof [29] of type soundness can be 
constructed by defining an operational semantics for Safe 
Concurrent Java (by extending the operational semantics of 
Classic Java [16]) and then proving that well-typed programs 
do not reach an error state and that the generalized subject 
reduction theorem holds for well-typed programs. The sub- 
ject reduction theorem states that the semantic interpreta- 
tion of a term’s type is invariant under reduction. The proof 
is straight-forward but tedious, so it is omitted here. 


6.3. Runtime Overhead 


The system described so far is a purely static type system. 
The ownership relations and the lock levels are used only for 
compile-time type checking and are not preserved at run- 
time. Consequently, Safe Concurrent Java programs have 
no runtime overhead when compared to regular Concurrent 
Java programs. In fact, one way to compile and run a Safe 
Concurrent Java program is to convert it into a Concurrent 
Java program after type checking, by removing the type pa- 


class A<oal, oa2> {...}; 
class B<ob1i, ob2, ob3> extends A<ob2, ob3> {...}; 


class C<oci> { 
void m(B<thisThread, this, oc1i> b) { 
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Figure 12: An Incompletely Typed Method 


rameters, the lock level declarations, the accesses clauses, 
and the locks clauses from the program. 


The Java language, however, is not a purely statically-typed 
language. Java allows downcasts that are checked at run- 
time. Suppose an object with declared type Object(o) is 
downcast to Vector(o,e). Since the result of this operation 
depends on information that is only available at runtime, 
our type checker cannot verify at compile-time that e is the 
right owner parameter even if we assume that the object is 
indeed a Vector. To safely support the Java downcast opera- 
tion, our implementation keeps some ownership information 
at runtime, but only for objects that can be potentially in- 
volved in downcasts into types with multiple parameters. 
Section 12 describes our implementation. 


The extra type information available in our system can be 
also used to enable program optimizations. For example, 
objects that are known to be thread-local can be allocated 
in a thread-local heap instead of the global heap. A thread- 
local heap may be separately garbage collected, and when 
the thread dies, the entire space in the thread-local heap 
may be reclaimed at once. 


7 Type Inference 


Although our type system is explicitly typed in principle, it 
would be onerous to fully annotate every method with the 
extra type information that our system requires. Instead, 
we use a combination of inference and well-chosen defaults 
to significantly reduce the number of annotations needed in 
practice. We emphasize that our approach to inference is 
purely intra-procedural and we do not infer method signa- 
tures or types of instance variables. Rather, we use a default 
completion of partial type specifications in those cases to 
minimize the required annotations. This approach permits 
separate compilation. Section 7.1 below describes our intra- 
procedural inference algorithm, while Section 7.2 describes 
our default types. 


7.1 Intra-Procedural Type Inference 


In our system, it is usually unnecessary to explicitly aug- 
ment the types of method-local variables with their owner 
parameters. A simple inference algorithm can automatically 
deduce the owner parameters for otherwise well-typed pro- 
grams. We illustrate our algorithm with an example. Fig- 
ure 12 shows a class hierarchy and an incompletely-typed 
method m. The types of local variables al and b1 inside m do 
not contain their owner parameters explicitly. The inference 
algorithm works by first augmenting such incomplete types 
with the appropriate number of distinct, unknown owner 


6 A<x1, x2> al; 
7 B<x3, x4, x5> bi; 


Figure 13: Types Augmented With Unknown Owners 


Statement 8 
Statement 9 


thisThread, x4 = this, x5 = ocl 
x4, x2 = x5 


Figure 14: Constraints on Unknown Owners 


parameters. For example, since al is of type A, the algo- 
rithm augments the type of al with two owner parameters. 
Figure 13 shows augmented types for the example in Fig- 
ure 12. The goal of the inference algorithm is to find known 
owner parameters that can be used in place of the each of 
the unknown owner parameters to make the program be well- 
typed. 


The inference algorithm treats the body of the method as a 
bag of statements. The algorithm works by collecting con- 
straints on the owner parameters for each assignment or 
function invocation in the method body. Figure 14 shows 
the constraints imposed by Statements 8 and 9 in the ex- 
ample in Figure 12. Note that all the constraints are of 
the form of equality between two owner parameters. Con- 
sequently, the constraints can be solved using the standard 
Union-Find algorithm in almost linear time [10]. If the so- 
lution is inconsistent, that is, if any two known owner pa- 
rameters are constrained to be equal to one another by the 
solution, then the inference algorithm returns an error and 
the program does not type check. Otherwise, if the solution 
is incomplete, that is, if there is no known parameter that is 
equal to an unknown parameter, then the algorithm replaces 
all such unknown parameters with this Thread. 


7.2 Default Types 


In addition to the intra-procedural type inference, our sys- 
tem provides well-chosen defaults to reduce the number of 
annotations needed in many common cases. We are also 
considering allowing user-defined defaults to cover specific 
sharing patterns that might occur in user code. The follow- 
ing are some default types currently provided by our system. 


If a class is declared to be default-single-threaded, our sys- 
tem adds the following default type annotations wherever 
they are not explicitly specified by the programmer. If the 
type of any instance variable in the class or any method ar- 
gument or return value is not explicitly parameterized, the 
system augments the type with an appropriate number of 
thisThread owner parameters. If a method in the class does 
not contain an accesses or locks clause, the system adds an 
empty accesses or locks clause to the method. With these de- 
fault types, single-threaded programs require no extra type 
annotations. 


If a class is declared to be default-self-synchronized, our sys- 
tem adds the following default type annotations wherever 
they are not explicitly specified by the programmer. If the 
type of any instance variable is not explicitly parameterized, 
the system augments the type with an appropriate number of 
this owner parameters. If the type of any method argument 
or return value is not explicitly parameterized, the system 


defn ::= class cn(owner formal*) whereclause 
extends c body 
formal :=  f | self:v 
locklevel ::= cnl|v 
whereclause ::= where (locklevel > locklevel)* 
locksclause ::= locks (locklevel* lock*) 


v formal lock level names 


ay 


Figure 15: Grammar Extensions for Level Polymorphism 


class Stack<self:v, elementOwner> where (v > Vector.1) { 
Vector<self:Vector.1, elementOwner> vec = new Vector; 


int size() locks(this) { 
synchronized (this) { 
return vec.size(); 
}} 
} 
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Figure 16: Self-Synchronized Stack Using Vector 


augments the type with fresh formal owner parameters. If a 
method in the class does not contain an accesses clause, the 
system adds an accesses clause that contains all the method 
arguments. If a method in the class does not contain a locks 
clause, the system adds a locks(this) clause. With these de- 
fault types, many self-synchronized classes require almost no 
extra type annotations. 


8 Lock Level Polymorphism 


This section describes how our type system supports poly- 
morphism in lock levels. In the type system described in 
Section 5, the level of each lock was known at compile-time. 
But programmers may sometimes want to write code where 
the exact levels of some locks may not be known statically— 
only some ordering constraints among the unknown lock 
levels may be known statically. Lock level polymorphism 
enables this kind of programming. To simplify the presen- 
tation, this section describes how our type system supports 
lock level polymorphism in the context of Safe Concurrent 
Java. Figure 15 shows how the grammar of Safe Concurrent 
Java can be extended to support lock level polymorphism. 


Classes may be parameterized with formal lock level param- 
eters in addition to formal owner parameters. Ordering con- 
straints among the formal lock level parameters may be spec- 
ified using where clauses. This is somewhat similar to the use 
of where clauses in [11, 24]. Figure 16 shows part of a self- 
synchronized Stack implemented using the self-synchronized 
Vector shown in Figure 11. In the example, the lock level 
of the this Stack object is a formal parameter v. The where 
clause constrains v to be greater than Vector.|. It is therefore 
legal for the synchronized Stack.size method to call the syn- 
chronized Vector.size method. The type checker statically 
verifies that locks are acquired in the descending order of 
lock levels. 


9 Condition Variables 


This section describes how our system prevents deadlocks in 
the presence of condition variables. Java provides condition 
variables in the form of the wait and notify methods on Ob- 
ject. Since a thread can wait on a condition variable as well 
as on a lock, it is possible to have a deadlock that involves 


locksclause ::= locks ([oo]opt locklevel* lock*) 


e ... | e.wait | e.notify 


Figure 17: Grammar Extensions for Condition Variables 


condition variables as well as locks. There is no simple rule 
like the ordering rule for locks that can avoid this kind of 
deadlock. The lock ordering rule depends on the fact that a 
thread must be holding a lock to keep another thread wait- 
ing for that lock. In the case of conditions, the thread that 
will notify cannot be distinguished in such a simple way. 


To simplify the presentation, this section describes how our 
type system handles condition variables in the context of 
Safe Concurrent Java. Figure 17 shows how the grammar 
of Safe Concurrent Java can be extended to support condi- 
tion variables. The expression e.wait and e.notify are similar 
to the wait and notifyAll methods in Java. e must be a fi- 
nal expression that evaluates to an object, and the current 
thread must hold the lock on e. On executing wait, the cur- 
rent thread releases the lock on e and suspends itself. The 
thread resumes execution when some other thread invokes 
notify on the same object. The thread re-acquires the lock 
on e before resuming execution after wait. 


To prevent deadlocks in the presence of condition variables, 
our system enforces the following constraint. A thread can 
invoke e.wait only if the thread holds no locks other than the 
lock on e. Since a thread releases the lock on e on executing 
e.wait, the above constraint implies that any thread that 
is waiting on a condition variable holds no locks. This in 
turn implies that there cannot be a deadlock that involves 
a condition variable. To statically verify that a program 
respects the above constraint, our type system requires that 
any method m that contains a call to e.wait must have a 
locks (co) clause or a locks (co e) clause. The former locks 
clause indicates that a thread holds no locks when it invokes 
m, while the later locks clause indicates that a thread can 
only hold the lock on e when it invokes m. Within the 
method, our type checker ensures when type checking e.wait 
that the lockset contains only the lock on e and no other 
lock. The rules for type checking are shown below, assuming 
the locks clause of the enclosing method is included in the 
environment EF. 


[EXP WAIT] 


P; E+ Method has locks(oo [e]opt) clause 
P;EFenae Is = {e} 
P; E; 1s; lmin F e.wait : int 


[EXP NOTIFY] 
P; Efgnae e Els 


P; E; ls; lmin / e-notify : int 


10 ‘Tree-Based Partial Orders 


This section describes how our type system supports tree- 
based partial orders. Figure 18 shows the grammar exten- 
sions to Safe Concurrent Java to support tree-based partial 


field ::=  [finallopt [tree]ope t fd = e 


Figure 18: Grammar Extensions for Tree Ordering 


Stmt Information in Environment After 
Ht Checking Statement in Figure 2 
23 x=this.right 

v=x.left 
w=v.right 


24 x=this.right | w is Root | this not in Tree(w) 
v=x.left x not in Tree(w) 
v not in Tree(w) 
this not in Tree(v) 
x not in Tree(v 
w not in Tree(v) 
this not in Tree(x) 
v not in Tree(x 


25 x=this.right | v is Root 
w=x.left 


26 v=this.right | x is Root 
w=x.left 

27 v=this.right 
w=x.left 
x=v.right 


Figure 19: Illustration of Flow-Sensitive Analysis 


orders. Programmers can declare fields in objects to be tree 
fields. If object x has a tree field fd that contains a pointer 
to object y, we say that there is a tree edge fd from x to y. 
x is the parent of y and y is a child of x. Our type system 
ensures that the graph induced by the set of all tree edges in 
the heap is indeed a forest of trees. Any data structure that 
has a tree backbone can be used to describe the partial order 
in our system. This includes doubly linked lists, trees with 
parent pointers, threaded trees, and balanced search trees. 


Locks that belong to the same lock level are further ordered 
according to the tree-order. Suppose x and y are two locks 
(that is, they are objects that own themselves) and that x 
and y belong to the same lock level. Suppose a thread t holds 
the lock on x and reads a tree field fd of x to get a pointer to 
y. So y is a child of x. Our type system then allows thread 
t to also acquire the lock on y while holding the lock on x. 
Note that as long as ¢t holds the lock on z, no other thread 
can modify x, so no other thread can make y not a child of 
x. The type checking rule is shown below, assuming that for 
every pair of final variables x and y, environment F contains 
information about whether the objects x and y are related 
by tree edges. 


[EXP SYNC CHILD] 


Vyels (P; Et level(y) > Imin or P; EF y is an ancestor of «) 


ze’ €ls P; Et} @ isa child of x’ 
P; Et level(x) = level(x’) = lmin 
P; E; ls, e3lmin Fe: t 
P; E; 1s; lyin / synchronized x ine: t 


Figure 2 presents an example with a tree-based partial order. 
The Node class is self-synchronized, that is, the this Node 
object owns itself. The lock level of the this Node object 


field ::=  [finallopt [tree]opt t fd = e | final dag t fd = e 


Figure 20: Grammar Extensions for DAG Ordering 


is the formal parameter v. A Node has two tree fields left 
and right. The Nodes left and right own themselves and also 
belong to lock level v. Nodes left and right are therefore 
ordered less than the this Node object in the partial order. 
In the example, the rotateRight method acquires the locks 
on Nodes this, x and v in the tree-order. 


Our type system allows a limited set of mutations on trees 
at runtime. The type checker uses a simple intra-procedural 
intra-loop flow-sensitive analysis to check that the mutations 
do not introduce cycles in the trees. We illustrate our flow- 
sensitive analysis using the example in Figure 2. The type 
checker keeps the following additional information in the en- 
vironment F for every pair of final variables x and y: 1) 
If the objects x and y are related by a tree edge, 2) If x 
is the root of a tree, and 3) If x is a root and y is not in 
the tree rooted at x. Figure 19 contains the information 
stored in the environment after the type checking of vari- 
ous statements in the rotateRight method in Figure 2. Since 
the analysis is flow-sensitive, the environment changes after 
checking each statement. 


The rules for mutating a tree are as follows. Deleting a tree 
edge (for example, setting a tree field to null or over-writing 
a tree field) requires no extra checking. A tree edge from 
x to x’ may be added only if x’ is the root of a tree and 
x is not in the tree rooted at x’. The rule is shown below. 
Note that if x’ is a unique pointer to an object (for example, 
x’ is newly created using the expression new c), then 2’ is 
trivially a root. Similarly, if x is a unique pointer, then x 
cannot be in the tree rooted at 2’. 


[EXP TREE ASSIGN] 


P; E; 1s; lmin F x : en(o1..n) 
PF (tree t fd) € cn(fi..n) 
P; E+ RootOwner(z) =r re€ls 
P; E; 1s; lnin | x! : t[a/this][o1/fi]..[on/ fn] 
P; E' 2’ is Root 
P; E+ & not in Tree(2’) 
P; E; 1s; lnin F vw. fd = x’ : t[a/this][o1/f1]..[on/ fn] 


11 DAG-Based Partial Orders 


Our type system also allows programmers to use directed 
acyclic graphs (DAGs) to describe the partial order. Fig- 
ure 20 shows the grammar extensions to Safe Concurrent 
Java to support DAG-based partial orders. Programmers 
can declare fields in objects to be dag fields. Our type sys- 
tem ensures that no object can be both part of a tree and 
part of a DAG. Locks that belong to the same lock level are 
further ordered according to the DAG-order. DAGs used for 
partial orders are monotonic. DAG fields cannot be modified 
once initialized. Only newly created nodes may be added to 
a DAG by initializing the newly created nodes to contain 
DAG edges to existing DAG nodes. 


11 


Lines Lines 
Program | of Code | Changed 
elevator 523 15 
http 563 26 
chat 308 22 
stock quote 242 12 
game 087 11 
phone 302 10 


Figure 21: Programming Overhead 


12 Implementation 


We have a prototype implementation of our type system. 
Our implementation handles all the features of the Java lan- 
guage including threads, constructors, arrays, exceptions, 
static fields, interfaces, and runtime downcasts. The type 
system we implemented is also more expressive than the type 
system we described formally in earlier sections of this pa- 
per. Our implementation supports unsynchronized accesses 
to immutable objects and objects with unique pointers [3]. 


Our implementation also supports parameterized methods 
in addition to parameterized classes. This is useful in many 
cases. For example, the PrintStream class has a print(Object) 
method. Let us say, the Object argument is owned by Ob- 
jectOwner. If we did not have parameterized methods, then 
the PrintStream class would have to have an ObjectOwner pa- 
rameter. Not only would this be unnecessarily tedious, but 
it would also mean that all objects that can be printed by 
a PrintStream must have the same protection mechanism. 
Having parameterized methods allows us to implement a 
generic print(Object) method. 


We also support safe runtime downcasts in our implementa- 
tion. This is important because Java is not a fully statically- 
typed language. It allows downcasts that are checked at 
runtime. Suppose an object with declared type Object(o) is 
downcast to Vector(o,e). We cannot verify at compile-time 
that e is the right owner parameter even if we assume that 
the object is indeed a Vector. We use type passing to sup- 
port safe runtime downcasts. Our technique is similar to 
the technique for implementing parametric polymorphism 
in Java described in [27]. We only keep runtime ownership 
and lock level information for objects that are potentially 
involved in downcasts to types with multiple parameters. 


To gain preliminary experience, we implemented several Java 
programs in our system. These include elevator, a real time 
discrete event simulator [28, 7], an http server, a chat server, 
a stock quote server, a game server, and phone, a database- 
backed information sever. These programs exhibit a variety 
of sharing patterns. Our type system was expressive enough 
to support these programs. In each case, once the sharing 
pattern of the program was known, adding the extra type 
annotations was a fairly straight forward process. Figure 21 
presents a measure of the programming overhead involved. 
The figure shows the lines of code that needed type annota- 
tions. 


In our experience, we found that threads rarely need to hold 


multiple locks at the same time. In cases where threads 
do hold multiple locks simultaneously, the threads usually 
acquire the multiple locks as they cross abstraction bound- 
aries. For example, in elevator, threads acquire the lock ona 
Floor object and then invoke synchronized methods on a Vec- 
tor object. Even though such programs use an unbounded 
number of locks, these locks can be classified into a small 
number of lock levels. These programs are therefore easily 
expressed in our type system. 


We also note that in cases where threads do hold multiple 
locks simultaneously, it is usually because of conservative 
programming. In the elevator example mentioned above, 
the Vector object is contained within the Floor object. Ac- 
quiring the lock on the Vector object is thus unnecessary. In 
fact, programmers can use an ArrayList instead of a Vector. 
The reason many Java programs are conservative is because 
there is no mechanism in Java to prevent data races or dead- 
locks. For example, Java programs that use ArrayLists risk 
data races because ArrayLists may be accessed without ap- 
propriate synchronization in shared contexts. But since our 
type system guarantees data race freedom and deadlock free- 
dom, programmers can employ aggressive locking disciplines 
without sacrificing safety. 


13. Related Work 


There has been much research on approaches that help pro- 
grammers detect data races and deadlocks in multithreaded 
programs. 


13.1 Static Tools 


Tools like Warlock [26] and Sema [20] use annotations sup- 
plied by programmers to statically detect potential data 
races and deadlocks in a program. The Extended Static 
Checker for Java (Esc/Java) [21, 12] is another annotation 
based system that uses a theorem prover to statically detect 
many kinds of errors including data races and deadlocks. 
Another recent system [14] assumes bugs to be deviant be- 
havior to statically extract and check correctness conditions 
that a system must obey without requiring programmer an- 
notations. While these tools are useful in practice, they 
are not sound, in that they do not certify that a program 
is race-free or deadlock-free. For example, ESC/Java does 
not always verify that a partial order of locks declared in a 
program is indeed a partial order. 


13.2. Dynamic Tools 


There are many systems that detect data races and dead- 
locks dynamically. These include systems developed in the 
scientific parallel programming community like [13, 18], tools 
like Eraser [25], and tools for detecting data races in Java 
programs like [28, 7]. Eraser dynamically monitors all lock 
acquisitions to test whether a linear order exists among the 
locks that is respected by every thread. Dynamic tools have 
the advantage that they can check unannotated programs. 
However, these tools are not comprehensive—they may fail 
to detect certain errors due to insufficient test coverage. 


13.3. Language Mechanisms 


To our knowledge, Concurrent Pascal is the first race-free 
programming language [5]. Programs in Concurrent Pascal 
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used synchronized monitors to prevent data races. But mon- 
itors in Concurrent Pascal were restricted in that threads 
could share data with monitors only by copying the data. A 
thread could not pass a reference to an object to a monitor. 


More recently, researchers have proposed type systems to 
prevent data races in object-oriented programs. Race Free 
Java [15] extends the static annotations in Esc/Java into a 
formal race-free type system. Guava [2] is another dialect of 
Java for preventing data races. Our race-free type system 
published earlier [3] lets programmers write generic code to 
implement a class, and create different objects of the same 
class that have different protection mechanisms. Our type 
system described in this paper extends the race-free type 
system [3] to prevent both data races and deadlocks. 


13.4 Message Passing Systems 


There are several systems that statically check for races and 
deadlocks in message passing systems [19, 6]. The program- 
ming model used in these systems is different from the Java 
programming model. Unlike Java programs, these programs 
do not access shared objects in a heap. 


13.5 Related Type Systems 


Our type system is related to several other type systems 
discussed in literature, even though their goals and tech- 
niques were different. The concept of object ownership used 
in this paper is similar to the one in ownership types [9, 
8]. Ownership types were motivated by software engineer- 
ing principles and were used to restrict object aliasing. Our 
way of parameterizing classes is similar to the proposals for 
parametric types for Java [24, 4, 1, 27], except that the pa- 
rameters in our system are values and not types. Our use of 
where clauses is somewhat similar to the use of where clauses 
in [11, 24]. Our accesses clauses and locks clauses are similar 
to type and effect systems [23]. 


14 Conclusions 


Multithreaded programming is difficult and error prone. This 
paper presents a new static type system for multithreaded 
programs; well-typed programs in our system are guaranteed 
to be free of both data races and deadlocks. Our type sys- 
tem allows programmers to partition the locks into a fixed 
number of lock levels and specify a partial order among the 
lock levels. Our system also allows programmers to use re- 
cursive tree-based data structures to further order locks that 
belong to the same lock level. The type checker then stat- 
ically verifies that whenever a thread holds more than one 
lock, the thread acquires the locks in the descending order. 
The type checker also uses an intra-procedural intra-loop 
flow-sensitive analysis to check that mutations to trees used 
for describing partial orders do not introduce cycles in the 
partial order, and that the changing of the partial order does 
not lead to deadlocks. We do not know of any other sound 
static system for preventing deadlocks that allows changes 
to the partial order at runtime. We implemented our type 
system for Java. Our preliminary experience indicates that 
our type system is sufficiently expressive and requires little 
programming overhead. 
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Appendix 
A Type System for Safe Concurrent Java 


This appendix presents the type system described in Section 5. The grammar for the type system is shown below. 


P w= defn*e 
defn ::= class cn(owner formal*) extends c {level* field* meth*} 
c n= cn(owner+) | Object(owner+) 
owner = formal | self:en.1 | thisThread | einai 
level ::= LockLevel 1 = new | LockLevel | < cn.I* > cn.l* 
meth ::= t mn(arg*) accesses (efinai*) locks (cn.l* lock*) {e} 
field ::=  [finallopt t fd = e 
arg := [finallope t x 
t =  c | int | boolean 
formal — 
e n= newc|az|x2=e|e.fd | e.fd = e| e.mn(e*) | e;e | let (arg=e) in {e} | if (e) then {e} | synchronized (e) in {e} | fork (x*) {e} 
final = 2€ 
lock = final 
cn € class names 
fda € field names 
mn € method names 
x € variable names 
f € owner names 
t € lock level names 


We first define a number of predicates used in the type system informally. These predicates (except the last one) are based 
on similar predicates from [16] and [15]. We refer the reader to those papers for their precise formulation. 


Predicate Meaning 

ClassOnce(P) No class is declared twice in P 

WFClasses(P) There are no cycles in the class hierarchy 

FieldsOnce(P) No class contains two fields with the same name, either declared or inherited 


MethodsOnce(P) | No class contains two methods with the same name 

OverridesOK(P) Overriding methods have the same return type and parameter types as the methods being overridden 
The accesses clause of an overriding method must be the same or a subset of the overridden methods 
The locks clause of an overriding method must be the same or a subset of the overridden methods 
LockLevelsOK(P) | There are no cycles in the lock levels 


A typing environment is defined as E ::= 0 | E, [final]opt t « | E, owner f 

A lock set is defined as Is ::= thisThread | Is, lock | ls, RO(efinai)}; Where RO(e) is the root owner of e 

A minimum lock level is defined as Imin ::= 00 | en. | LUB(eny.ly ... cng-le); Where LUB(en,.1, ... cng.le) > engl Vi=1..k 
Note that RO(e) and LUB(...) are not computed—they are just expressions used as such for type checking. 


We define the type system using the following judgments. We present the typing rules for these judgments after that. 


Judgment Meaning 

PoP os t program P yields type t 

P+ defn defn is a well-formed class definition 

P; Et wf FE is a well-formed typing environment 

P;EFE t is a well-formed type 

P; EF ty <: tg ti is a subtype of te 

P; E Fowner 0 o is an owner 

P Prevei (ered cn.l is a well-formed lock level 

Pt en,.l4 < cng.le cnj.l; is less than cng.l2 in the partial order formed by lock levels 

Ptrenl < lmin cn.l is less than lin in the partial order formed by lock levels 

P; E+ level(e) = cnl e is a final expression that owns itself and the lock level of e is cn.l 

P; E+ level(e) < lmin e is a final expression that owns itself and the lock level of e is less than [min 
P; EF gna e: t e is a final expression with type t 

P; EF field init field init is a well-formed field initializer 

PF field € cn(fi..n) class cn with formal parameters f1,.n declares/inherits field 

P- meth € cn(fi..n) class cn with formal parameters f1..n declares/inherits meth 

P; EF meth meth is a well-formed method 

P; E+ RootOwner(e) = r | r is the root owner of the final expression e 

P;EFe:t expression e has type t 

P; E;1s;lmin be: t expression e has type t and evaluating e will not create data races or deadlocks 
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-P:t P } defn 
[PROG] [CLASS] 
ClassOnce(P) WFClasses(P) FieldsOnce(P) if (f1 #4 self:en’.l’ | thisThread) then g; = owner f; 
MethodsOnce(P) OverridesOK(P) LockLevelsOK(P) Viz2..n gi = owner fi E = gi..n, final cn(fi..n) this 
P= defni.ne Pt defn; P; 0; thisThread; co F ce: t P;BEFe P; EF field; P; Et meth; 
EPs t PF class cn(fi.n) extends c {field1,.; methi..x} 
P; EL wf P;EFt 
[ENV 0] [ENV OWNER] [ENV X] [TYPE INT] [TYPE BOOLEAN] [TYPE OBJECT] 
P;Et wf f ¢Dom(£) P;Ett « ¢ Dom(£) P; E Fowner © 
P;O- wf P; E, owner f+ wf P; E, [final]op, t 2 F wf P; EF int P; E’'§ boolean P; E+ Object(o) 
[TYPE SHARED CLASS] [TYPE THREAD-LOCAL CLASS] [TYPE C] 


Pt class en(self:en’.l’ fo.n) 


01 = self:en’.l’ P; E bowner O1,.n 0, = thisThread 


P+ class en(thisThread fo.) ... 


Pt class en(fi.n) ... 


P; E Fowner 01..n fi A self:en’.l’ | thisThread P; E bowner O1..n 


P; E- cn(01..n) P; EE 


P; Eb ty <:t2 


[SUBTYPE REFL] [SUBTYPE TRANS] 


P;EFt 
PeEPe<i¢ 


P,;EK t <:tg P; EF te <: tg 
P; EF ty <: tg 


P; E Fowner ° 


[OWNER THISTHREAD] [OWNER OTHERTHREAD] 


[OWNER SELF] 


cn(01..n) P; Et en(01..n) 


[SUBTYPE CLASS] 
P; E- en (01..n) 
Pt class cni(fi..n) extends cn2(f1 ox) ... 
P; Eb cny(01..n) <: cne(fi o*) [01/fi].-[on/ fn] 


[OWNER EXP] [OWNER FORMAL] 


P;Eb wf 


P Fyeve en.l P; EF ginay e: t E = Ej, owner f, E2 


P; E Fowner thisThread P; E Fowner otherThread P; 


P Fieve! en-l Pr eny.ly < eng.lg 


[LEVEL] 
PF class en... {... Locklevel 1 ...} 


(LEVEL <] 


PF class en,... {... LockLevel ly < ... cng.le ... 


E Fowner self:en.l P; E Fowner € P; E Fowner f 


(LEVEL >] 
PF class eng... {... LockLevel lo >... cni.ly ... 


} } 


P Fieve cn.l 


Prenl<l 


min 


[LEVEL < INFTY [LEVEL < LUB] 
bin SEU Bo Git ae 


P Fisyei en.l 


lmin = CO 


P Fievel cen. P 


Pk en,.l, < eng.le Pk en, < cng.le 
P; E+ level(e) = en.l 
[LEVEL < CN.L] (LEVEL TRANS] {[LEVEL(EXP)] 


Pken'l < lmin 
Pt en. < en’. 


t / 
lmin = cn'.l 


Fk en.l < en’.l’ P; EF ginal e: en’ (self:en.l ...) 


Pten.l < lnin Pt en. < lnin 


P; EF level(e) < lL P; E Final & 


min 


Pt endl < lmin 


Ptenl < lnin P; EF level(e) = en. 


P; EF field init 


[FIELD INIT] 


P; E; thisThread; co Fe: t 


[LEVEL < LEVEL MIN] FINAL VAR] [FINAL REF] 
P; Et level(e) = cn.l P;Et wf PF (final t fd) € cn(fi..n) 
Peek < Vea E = Ej, final t 2, Eo P; E F ginal € : cn(01..n) 
P; E+ level(e) < Imin P; E Final xv: t P; EF gina e.fd: tlo1/fi)..[on/fn] 


PE field € c 


[FIELD DECLARED] [FIELD INHERITED] 


P; EF ([finallopt t fd =e 


Pt meth €c 


[METHOD DECLARED] 


PF class en(fi.n).-. {... field ...} 


Pt class cn(fi.n)... {... field ...} 


P+ class en’ (gi..m) extends cn(o1,.n)--- 


PF class en(fi..n)... {... meth ...} 


PF field € cn(fi..n) 


PFE field[o1/fi}.-.[on/fn] € en’(g1..m) 


P+ meth € cn(fi..n) 
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P; Et} method 


[METHOD INHERITED] METHOD] 
Pt class en(fi..n)... {... meth ...} P; E, argi.in Fein Cc? t§ =P; BE, argiin F RootOwner(e;) Se. 
Pf class en’(gi..m) extends cn(o1..n)..- P; E, argi..n F level(lockj) = en§.U lmin = LUB(enj.ly jEl.k en’, U J€1.1) 
P+ meth[o1/fi]--[on/fn] € en’(g1..m) P; E, argi..n; thisThread, r1..+; lmin F e: t 


P; Et t mn(argi..n) accesses(e1..,) locks(en;.1; JElk locky..1) {e} 


P; E+ RootOwner(e) = r 


[ROOTOWNER THISTHREAD] [ROOTOWNER OTHERTHREAD] [ROOTOWNER SELF] 
P; Et e: en(thisThread ox) P; Et e: cn(otherThread ox) P; Ete: cnself:en’.l’ ox) 
P; EF RootOwner(e) = thisThread P; E+ RootOwner(e) = otherThread P; E+ RootOwner(e) = e 


P;EbFe:t 


[ROOTOWNER FINAL TRANSITIVE] [ROOTOWNER FORMAL] [EXP TYPE] 
P; Ete: cn(o1..n) P; Ete: cn(o1..n) 
P; Et gina 01: ¢c1 P; Eb RootOwner(o1) = r P; E Fowner 01 Ii. P; E:ls; ote: t 
P; E+ RootOwner(e) = r P; E+ RootOwner(e) = RO(e) P;EFe:t 


P; E;lste:t 


[EXP SUB] [EXP NEW] [EXP VAR] {EXP VAR ASSIGN] 
P; E; ls; lmin be: t P; Et wf P; Et wf 
P; E; ls; lmin Ft! <:t PER E = E,, [finallopt t x, E2 E=E,,t2, Eq P; E;ls;lmin te: t 
P; E;ls;lmin Fe: t P; E; ls; lmin Fk newc: c P; E; ls; lmin au: t P; E;ls;lmin Fa =e: t 
[EXP SEQ] [EXP LET] [EXP IF] 
P; E; 1s; lmin F e1: ti arg = [finallope te P; E;1s;lmin Fe: t P; E; 1s; lmin / e1 : boolean 
P; E; 1s; lin - e2 : te P; E, arg; ls; lmin - e : t! P; E; 1s; lin - e2 : te 
P; Ex ls; laia P @14 €2 > te P; E; 1s; lnin ' let (arg = e) in {e’} : t’ P; E; 1s; lmin + if (e1) then {eo} : t 
[EXP REF] [EXP ASSIGN] 
P; E; ls; lmin / @: en(o1..n) PF ([finallope t fd) € en(fi..n) P; E; 1s; lnin F €: en(o1..n) Pt (t fd) € cn(fi..n) 
P; Et RootOwner(e) =r ré€ls P; E+ RootOwner(e) =r ré€ls 
P; E; 1s; lnin + e’ : t[e/this][o1/f1]..[on/fn] 
P; E; 1s; lmin + e.fd: t[le/this][o1/f1]..[on/ fn] P; E; 1s; lmin + e.fd =e’ : t[e/this][01/f1]..[on/fn] 
[EXP SYNC] [EXP SYNC REDUNDANT] [EXP FORK] 
P; EF level(e1) = cn. P; E: ls; lin F vi: ti 
Pten.l < lmnin e1 Els gi = final t;[otherThread/thisThread] x; 
P; E; ls, e1; en.l bk e2: te P; E; 1s; lmin  e2: te P; gi..n; thisThread; co Fe: t 
P; E; 1s; lmin / synchronized e1 in eg : ta P; E; ls; lmin / synchronized e1 in eg : te P; E; ls; lin | fork (@1..n) {e} : int 


[EXP INVOKE] 
P; E; 1s; lmin F € : cn(01,.n) 
PE (t mn(tj yj 7©1°*) accesses(e’*) locks(cn.l* lock*) ...) € en(fi..n) 
P; E; 1s; lmin F ej : tj[e/this][o1/f1]..[on/ fn] 
P; E+ RootOwner(e’[e/this][o1/fi]..[on/fn]) =r; ri € ls 
Ptenili <lmin (P; EF level(lock;) < lmin) or (lock; € Is) 
P; E; 1s; lmin F e.mn(e1,.4) : t[e/this][o1/f1]..[on/ fn] 
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